iT邦幫忙

2021 iThome 鐵人賽

DAY 27
0

前面的篇章大部分著重 DDD 的戰術設計,這篇來說說戰略設計。

功能型團隊

在導入 DDD 前,我們審視後發現,過去的開發項目並沒有完全滿足其他部門的需求,導致對於同一需求開發多次;然而,當初的規格都是按照其他部門的說明內容去開的,那怎麼還會這樣呢?

舉個例子,行銷部門說"我想要在網站上加成就系統",接著 PM 開始問細節,要有幾個成就、頁面長這樣行不行等等,然後估時程、實作,實作完成後交付成果,最後行銷部門說: "好像沒有達到我們想要的目的"

這凸顯出了,我們的團隊其實是功能型團隊,其他部門說什麼我們就做什麼,但有時其實他們也不甚清楚想要什麼,導致做出來的東西並不能解決問題。

需求型團隊

假如連使用者都不清楚要甚麼了,開發團隊要怎麼知道呢?(通靈、讀心術)

以剛剛的例子,行銷部門說: "我想要在網站上加成就系統",這時候就可以追問為甚麼想要成就系統——是想要吸引新用戶?還是想要讓用戶留在網站的時間長一點?那是不是可以透過其他方法達成目的,像是加強 SEO?

對於其他部門想要的開發不能照單全收,要抱著打破砂鍋問到底的精神去了解背後的需求,而 DDD 的戰略設計中就有許多好用的技巧可以達到這個目的,比如共通語言(Ubiquitous Language)可以讓所有人在同一頁上討論、事件風暴(Event Storming)可以完成每個人對流程的共識等等。

下一篇會繼續聊聊,關於改變開發流程,團隊遇到的一些彆扭事件。


上一篇
[DAY26] 導入 DDD 時尚未深究的問題
下一篇
[DAY28] 戰略設計的彆扭事件
系列文
在 Ruby on Rails 中導入 Domain-Driven Design 是不是搞錯了什麼?30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言